Related Application
The following related U.S. applications are hereby incorporated by reference: U.S. application Ser. No. 08/680,270 entitled "Method and Apparatus for Describing an Interface Definition Language-Defined Interface, Operation, and Data Type" by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,681 entitled "Method and Apparatus Using Parameterized Vectors For Converting Interface Definition Language-Defined Data Structures into a Transport and Platform Independent Format" by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,298 entitled "Data Structure Representing An Interface Definition Language Source File" by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/678,295 entitled "Method and Apparatus for Performing Distributed Object Calls" by A. Schofield filed Jul. 11, 1996; U.S. application Ser. No. 08/680,202 entitled "Method and Apparatus for Asynchronously Calling and Implementing Objects" by A. Schofield, filed Jul. 11, 1996; U.S. application Ser. No. 08/680,266 entitled "Method and Apparatus for Performing Distributed Object Calls using Proxies and Memory Allocation" by A. Schofield filed Jul. 11, 1996.
1. Field of the Invention
The present invention relates to a method and apparatus for transporting data structures described in the Object Management Group's Interface Definition Language between heterogeneous platforms. More particularly, the present invention utilizes functions for removing the alignment from data structures and storing the data structures in a predetermined format for transport to a file or across heterogeneous platforms.
2. Background
Distributed object computing combines the concepts of distributed computing and object-oriented computing. Distributed computing consists of two or more pieces of software sharing information with each other. These two pieces of software could be running on the same computer or on different computers connected to a common network. Most distributed computing is based on a client/server mode. With the client/server model, two major types of software are utilized: client software, which requests the information or service, and server software, which provides the information or service.
Object-oriented computing is based upon the object model where pieces of code called "objects"--often abstracted from real objects in the real world--own data (called "attributes" in object-oriented programming parlance) and provide services through methods (also known as "operations" or "member functions"). The data and methods contained in an object may be "public" or "private." Public data may be altered by any other object. Most data, however, is private and accessible only to methods owned by the object. Typically, the methods operate on the private data contained in the object.
A collection of similar objects make up an interface (or "class" in C++ parlance). An interface specifies the methods and types of data contained in all objects of the interface. Objects are then created ("instantiated") based upon that interface. Each object contains data specific to that object. Each specific object is identified within a distributed object system by a unique identifier called an object reference.
In a distributed object system, a client sends a request (or "object call") containing an indication of the operation for the server to perform, the object reference, and a mechanism to return "exception information" (unexpected occurrences) about the success or failure of a request. The server receives the request and, if possible, carries out the request and returns the appropriate exception information. An object request broker ("ORB") provides a communication hub for all objects in the system passing the request to the server and returning the reply to the client.
On the client side, the ORB handles requests for the invocation of a method and the related selection of servers and methods. When an application sends a request to the ORB for a method to be performed on an object, the ORB validates the arguments contained in the request against the interface and dispatches the request to the server, starting it if necessary. On the server side, the ORB receives such requests, unmarshals the arguments, sets up the context state as needed, invokes the method dispatcher, marshals the output arguments, and returns the results to the client, thereby completing the object invocation.
Both client and server must have information about the available objects and methods that can be performed. Through the hiding of private data ("encapsulation" in object-oriented parlance), the client does not need to know how the request will be carried out by the server. Nevertheless, both client and server must have access to common interface definitions to enable communication therebetween. Currently, the standard language for distributed object computing is the Object Management Group's ("OMG") Interface Definition Language ("IDL").
A distributed object system developer defines the system's available interfaces in IDL. An interface includes one or more operations that can be performed on objects of that interface. Each operation may receive one or more parameters. Each parameter is of a particular IDL data type.
IDL includes several data types. Integers are represented through long and short, signed and unsigned integer data types. OMG IDL floating point types are float and double. The float type represents IEEE single-precision floating point numbers while the double type represents the IEEE double-precision floating point numbers. OMG IDL defines a char data type consisting of 8-bit quantities. The boolean data type is used to represent true/false values. The "any" type permits the specification of values that can express any OMG IDL type. Complex types, such as structures, unions, and templates are also represented.
IDL is designed to be used in distributed object systems implementing OMG's Common Object Request Broker Architecture ("CORBA"). In a typical CORBA system, interface definitions are written in an IDL-defined source file (also known as a "translation unit"). The source file is compiled by an IDL compiler that maps the source file to a specific programming language. The IDL compiler generates programming-language-specific files, including client stub files, header files, and server skeleton files. Client stub files are then compiled and linked into client applications and are used to make requests. Header files are linked into client and server applications and are used to define data types. Server skeleton files are linked into server applications and are used to map client operations on objects (requests) to methods in a server implementation.
When object calls are made, data structures are transported from one computer system to another (client-to-server and server-to-client). Such object calls may occur between identical systems, but are likely to be made across heterogeneous platforms using different operating systems, programming languages, and compilers. Once IDL source files have been compiled and mapped to a particular programming language, each independent compiler vendor will align data structures on the stack in a particular manner. Accordingly, both the client and the server systems may align data structures differently. Moreover, both the client systems may align parameters within a structure differently. If the client and server application do not understand each other's method of alignment, the transported data structure will become garbled and an error will occur.
In addition, the hardware utilized by the client and server may be different. For example, one computer may include a CPU that requires so-called "BIGendian" integer representation where the most significant byte is listed first. The other computer may include a CPU that requires "LITTLEendian" representation where the least significant byte is listed first. Data structures cannot be passed effectively between these two machines without reciprocal knowledge of each system.
Moreover, if clients and servers are required to have detailed knowledge of each other, a primary goal of object-oriented computing--encapsulation--is lost. Both the client and the server applications must write detailed alignment functions to ensure compatibility during object calls. This extra coding work makes distributed object computing inefficient.
Accordingly, there is a need for a method for converting IDL-defined data structures into a platform-independent format, such that converted data types can be transported effectively across heterogeneous systems.
In addition, there is a need for a method that reduces the amount of code and execution time required by client and server applications to implement object calls.